愈之 博客

A breath of fresh air

活久见！用扑克牌来管理你的工作 -- MEX二期项目管理乱谈

• 标签: 项目管理, 工作, 方法

上吊绳驱动开发

软件工程中有很多工作方法和理论，比如瀑布开发模式、敏捷开发、螺旋开发、测试驱动开发、行为驱动开发、领域驱动开发、 Scrum 等等，每种理论都有很多开发方法、工具和理论支撑。

甚至还有一种开发方式叫做DDD ( Deadline Driven Development ) ，俗称上吊绳驱动开发。

它的定义是这样的：拿到需求之后在开发者脖子上加一根随时间收紧的吊绳。如果规定时间内没有完成开发任务，开发者会被吊死。

类似于你在周末拼命写作业、写报告的感觉。上吊绳驱动开发基本上是一种借用未来的开发速度去满足特定的日期的方法。如果有在华为工作过开发的同学一定对此不会陌生。

话语权驱动开发

就像无法判定世界上哪个人是最漂亮的，哪一个人是最搓的。

在软件工程理论和方法上也没法说哪种方式和理论有绝对的优势。

产品经理一定会让研发人员作出时间估算，你很可能遇到过这样一个情景：

比如在需求未细化的情况下要求给出时间估算；

比如，就一句话描述需要做一个什么样的功能，但是具体页面长什么样，交互是什么都没有定下来的时候，就要求给时间估算；

现实情况是，根据产品发布时间否定研发人员的时间估算的例子比比皆是.

比如有个功能五天之后要上线，研发估了7天；产品说，不行重新估，五天后要发布；研发说，那这个功能七天做不完啊，加班也做不完啊。产品说，不行，那你想办法。于是研发妥协，好吧，估5天。产品很Happy表示说，早说5天不就行了嘛。于是研发苦逼的去加班。其实在这种情况下这并不是评估。

我想给这种方法下个定义，我觉得可以叫 「话语权驱动开发」，但还不知道怎么翻译成英文，暂时叫 Voice Driven Development 或者叫 Power Driven Development 吧。

当你有机会管理一个项目的时候，就能体会到各种思维方式的出发点，因为谁都不喜欢项目完成遥遥无期的感觉，项目越大沟通成本就越高，不可控因素也越多。

我想做一些改变

在MEX二期项目中（UED 团队内部的一个知识分享平台），我作为 PM 尝试引入一丢丢的新办法，来让项目推进更佳有趣和有序，我引入了 Scrum 工作法中的扑克估算方法到了需求会议上。

使用估算扑克来做工作量估算是很有效的，同时也是非常有趣的一种估算方式。

简单来说，扑克牌古算法就是一种项目成员使用扑克牌来估算工作量的方法。估算扑克由一组类似斐波纳契数列的数字组成，这些数字包括：0，0.5，1，2，3，5，8，20，40，?，∞，每幅扑克有四组这样的数字，可供4个人使用。如下图

估算扑克的使用方法：

1.每个团队成员拿到一组卡片，包括0，0.5，1，2，3，5，8，20，40，?，∞，共计12张。

  1. 产品负责人或者一名团队成员扮演阅读者的角色，他负责阅读需要估算产品Backlog的条目，并且询问大家是否有疑问。

  2. 团队讨论这个条目。

  3. 当团队理解了这个条目之后，每个团队成员按照自己的想法给出估算结果，并且选择对应的扑克出牌，估算结果不能告诉其他人，出牌时数字朝下扣在桌面上。

  4. 所有人都出牌之后，阅读者向大家确认是否都已经确定估算结果，确认后，数 ” 1, 2, 3″ ，大家同时展示估算结果。

  5. 团队评估不同的估算结果。确定我们是否想法一致？我们是否存在分歧？有没有什么是我没有考虑到的？团队共同讨论估算的差异，最终达成一致。

  6. 回到第二步，开始估算下一个条目。

大家的初次出牌

（没有估算扑克的时候，也可以使用其他相同作用的软件甚至图片来代替。如上图）

为什么要使用估算扑克来做估算

有人可能会问，在传统的做法中，我们一般是让一个专家或者项目经理来做估算，给出结果，然后团队照做就可以了，多个人都参与估算不是浪费时间吗？

使用估算扑克来做估算基于两个结论，

第一：团队的智慧要高于某一个人的智慧。

第二：真正参与工作的人做出的估计要高于其他人做出的估计。

估算扑克有效还有如下几个方面的原因：

  1. 传统估算通常是一个人在思考，而使用估算扑克估算时，鼓励跨职能团队的多个团队成员参与估算，团队成员可以从不同的视角来思考和分析问题，估算的过程中考虑的更加全面、估算也更加准确。

  2. 在估算的过程中，团队对估算的结果进行讨论和评判，在一个高度透明的环境下，估算的结果更加真实和客观。这样也避免了很多时候过于武断，或是拍脑袋做出的决定。

  3. 估算的过程也是一个知识分享和学习的过程，对某一个条目不清楚的成员通过其他成员的阐述会增加对该条目涉及到的要点的认识。

blabla，说了这么多不如开始做。

因此我们在MEX二期的工作量评估会议上试用了以下这种办法，在我不断重复说明下，同事们也很快理解了参与方法和流程，并给出了自己的估算。

在MEX二期评估会议上描述完需求的每个细节后，项目内的每一个同事，包括从来没写过代码的设计师同学都给出了自己对每一个需求的工作量估算。

希望我能给周围带来一些改变，让工作和做项目不再机械和枯燥，快乐工作，认真生活！